Fixes #662

What

• Added start and stop event for async tasks for each contract based on address.
• Added boolean flag to see if the task is still running for each contract based on address.
• For each contract when a rollback is needed, I empty the pending queue and I put the status of the newer transactions to pending.
• Same applies for accepted and undetermined transactions.
• Add order by created_at in get_pending_transactions() query to process the oldest first.
• The validator set is kept when rollbacked. This means that if a transaction has an increased validator set because of an appeal and that transaction need to be rollbacked to pending then it keeps the increased validator set (confirmed with Kiril).

Why

• Future transactions depend on each other. If one needs to go back to pending because of a successful appeal then the transactions that came after need to be rolled back.
• Creates value for the user.

Testing done

• Tested the new feature in the localhost

Decisions made

• I use asyncio.Event() to stop and start the tasks. Other option was to use a boolean flag.
• With while is_pending_queue_task_running() in rollback_transactions() I let the processing of the current transaction finish (until accepted or undetermined state) by the pending queue processor task to return it back to pending in a clean way. If it needs to be faster we can add a check for the stop event in the state transition while loop of exec_transaction() to stop after the current state transition so it doesn't need to go until accepted/undetermined but we need to see if it doesn't break anything.
• I empty the pending queue as I assume all transactions in the pending queue were send after the appealed accepted/undetermined transaction. So the _crawl_snapshot will get the rolled back transactions and the pending transactions that were already in the queue. Other option is to store the created_at of the appealed transaction in the consensusalgorithm class and only process if the current selected pending transaction's created_at is the same as the stored value. This will filter the newer that we present in the queue and they will be added at the end of the queue by the _crawl_snapshot.
• The leader appeal is processed by the appeal_window thread, implemented in PR feat: appeals undetermined transactions #657. Otherwise the code will be confusing when a leader appeal should be rollbacked when a validator appeal is successful (to select the correct validator set).
• I rollback all newer transactions for successful appealed accepted and undetermined transaction to the pending state. Other option is to not rollback when the contract state was not changed.

Checks

• I have tested this code
• I have reviewed my own PR
• I have created an issue for this PR
• I have set a descriptive PR title compliant with conventional commits

Reviewing tips

Check code changes and try it.

User facing release notes

A leader appeal success and validator appeal success will rollback all newer transactions to the pending status.